アジャイルイントロダクション : Agile 開発の光と影
https://m.media-amazon.com/images/I/41stvGbZbSL._SX260_.jpg
感想
訳が日本語としておかしい部分がちょくちょくある
ソフトウェア工学は、「ソフトウェア危機」 が認識され、1968 年頃がその起源である。
とか
内容メモ
本書の内容
アジャイルな考え方を検証 : アジャイルの原則、役割、プラクティス、成果物 組織がアジャイル開発を適用する際に気を付けるべきこと
最終的な評価
1 章 概要
2 章 アジャイル文章の分析
3 章 敵は大掛かりな事前作業の全て
4 章 アジャイルの原則
良い方法論の原則は、抽象的であると同時に反証可能であること
抽象的 : 原則とプラクティスの違い
プラクティスは原則を実現する手助けとなるもの
反証可能 : 常識との違い
分別のある人がその原則に同意しないこともあることを意味する
誰もが同意するようなものは常識であり、興味を持たれない
いくつか不足がある
プラクティスが含まれていたり、常識が含まれていたり、規範的でなく主張があったりする
5 章 アジャイルの役割
アジャイルの役割についての評価
最も面白いのは、管理者からプロダクトオーナーの役割を分離したこと
以下 2 つを分けるのは有用
日々のプロジェクトの方向付け
ビジネスのために何をすべきか定義し、それが実行されているかを確認すること
整合性と独立性のトレードオフ
1 人が両方を見る方が整合性を取れるが、2 人の方が独立性が高い
他の役割についても、統合するかどうかをトレードオフで検討できる
6 章 管理者のプラクティス
7 章 技術的なプラクティス
アジャイルに取り組む人たちは新しい考えを生み出している
8 章 アジャイルの成果物
9 章 アジャイル開発
10 章 アジャイルチームの扱い
アジャイルではタイムボックスの考え方を適用している → 機能と時間のどちらかしか保証できない
実際のところ、顧客がそれを受け入れるのかという問題がある
優秀なチームは、1 年以上、絶えず予算内で適切な機能を定刻通り提供できる
プロとアマチュアの違い
組織をアジャイルに変遷させる中で、アジャイルチームに責任を負ってもらうようにするのがデリケートな問題
合理的には、ゴールを中間的なステップ (マイルストーン) に分割する
11 章 アジャイル開発の評価 : 難点・誇張・利点
アジャイル開発の難点
事前タスクの軽視 (特に事前要求と事前設計)
抽象化を捨てている
機能単位の開発と依存関係の無視
依存関係追跡ツールの拒絶
事前の一般化の拒絶
テスト駆動開発のプロセスは真剣には取り組まれないし、そういった取り組みを用いると最新のテストに注目することにより視野を狭めうる、とのこと nobuoka.icon いまいちわからん
ドキュメントの軽視
アジャイル開発の誇張
持続可能なペースで作業する
最小の機能を生産する
アジャイル開発の利点・素晴らしい点
利点
チームのコミュニケーションの重要性
障害や無駄を識別して取り除くプラクティス
素晴らしい点
タイムボックス化したイテレーション
機能の全てにテストを記述すること
動作するソフトウェアを納品すること